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2 (57) Abstract: A method of authenticating a client (42) and a server (44) to each other via a gateway (46) in which the client uses a 
first encryption protocol between itself and the gateway and the server uses a second different encryption protocol between itself and 
Q the gateway tfie method comprising the steps of:installing in the server that the gateway is a inisted certification authority (48);the 
^ gateway issuing a digital certificate authenticating the client; andthe server verifying the digital certificate in order to confirm to itself 
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MEraOD A^ro SYSTEM FOR AXnHENTMCTOTON OF A MOBM USER VIA A GATEWAY 

The invention relates to autiientication and is particularly, but not exdusiveiy, 
related to a communications system. In one embodiment It relates to a wireless 
5 communications system. 

Communication over the internet uses the TCP/IP Protocol Family. TCP refers to 
Transport Control Protocol and IP refers to Internet Protocol. TCP/IP refers to a 
large set of protocols specified by the Internet Engineering Task Force (IETF). 
10 TCP/IP is the basic Intemet and Intranet communications protocol. It allows 
Information to be sent from one computer to Its destination through intermediate 
devices and separate networl^. 

The great flexibility of TCP/IP has led to Its worldwide acceptance. At the same 
15 time, the fact that TCP/IP allows Infomiatlon to pass through intemnedlate devices 
makes it possible for a third party to Interfere with communications in the following 

ways: 

Eavesdropping. Information remains intact, but Its privacy is compromised. For 
example, a third party can discover credit card details or intercept classified 
20 infonnation. 

Tampering. Infomiation in transit is altered and then sent on to an Intended 
recipient. For example, a third party can alter an order for goods. 
Impersonation. Infonnation passes to a third party which poses as an intended 
recipient. Impersonation can involve the third party pretending to be someone else 
25 or misrepresenting itself as a real organisation when it is not. For example the 
third party could represent Itself as a merchant and accept payments without 
sending any goods. 

Although these problems exist in wired environments, they are of particular 
30 concern in wireless environments, since third parties can receive wireless 
transmissions and make other wireless transmissions independently of a fixed 
location. 
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Encryption (cryptography) is used to deal witii iiiese problems. Encryption enables 
information to be rendered confidential so that it Is unintelligible to. an 
eavesdropper. In this way it provides , privacy. A recipient can verify that 
Information has not been modified in transit or detect when it has been modified. A 
recipient can determine that infomiation originates from its purported source, and 
so cart be authenticated, in addition, encryption can provide non-repudiation 
which prevents a sender of infomnation from claiming at a later date that It did not 
send the Infomnation. 



One fomi of encryption is symmetric-lcey encryption. In symmetric-key encryption, 
an encryption Icey can be calculated from a decryption I^ey and vice versa. With 
most symmetric algorithms, the same key is used for both encryption and 
decryption. Impternentatlons of symmetrio-key encryption can be highly efficient, 
15 so that users do not experiencie any significant time delay as a result of the 
encryption and decryption procedures. Symmetric-key encryption also provides a 
degree of authentication, since infonnatlon encrypted with one symmetric key 
cannot be decrypted with any other symmetric key. . 

20 Symmetric-key encryption is efifective only if the symmetric keys are kept secret by 
the two parties Involved. If anyone else discovers the keys, it affects both 
confidentiality and authentication. A person with an unauthorised symmetric key 
not only can decrypt messages sent with that key, but also can encrypt new 
messages and send them as if they came from one of the two parties who were 

25 originally using the key. 

Another form of encryption is public-key encryption. One version of public-key 
encryption is based on algorithms of RSA Data Security. Public-key encryption 
(also called asymmetric encryption) involves a pair of keys, a public key and a 
30 private key, associated with a party tliat needs to authenticate its identity 
electronically or to sign or to encrypt data. The public key must be authentic. A 
public key may be published, while the con-esponding private key must be kept 
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secret. A message encrypted by using the public key iand tlie encryption algorithm 



can only be decrypted by using the private key. Therefore if a party has been 
given the public key, it can use this Icey to encrypt messages which can only be 
decrypted by using the private key. In this way, privacy or oonfkientiarrty is 
5 provided. Conversely, a message encrypted by using the private key can only be 
decrypted by using the public key. Therefore, If a party has the private key, the 
party can use this key to encrypt messages which can be decrypted by another 
party having the public key. Messages which can be decrypted with the public key 
can only come from a party possessing the con'esponding private key. In this way, 
10 authentication or signature Is provided. 

Clearly it is important to ensure that any public key comes from its purported 
source. For example, a sender may generate a private and public key pair and 
send the public key to a receiver so that the receiver can be certain that messages 

15 signed by the private key are from the sender. However, If a third party Intercepts 
the sender's public key and substitutes a public key from a private and public key 
pair of its own, then the third party can intercept messages from the sender, open 
them with the sender's public key and then alter them and digitally sign them with 
its own private key. On receiving such a digitally signed messiage the receiver will 

20 believe that It comes from the sender. This does not just apply to altered 
messages, but also applies to impersonation, that Is a third party can send 
messages which are wholly fabricated. 

To deal with this problem a certification authority is used as is shown in Figure 1, 
25 This an^gement shows a sender 12, a receiver 14 and a certification authority 
(OA) 16. The CA 16 is connected to the sender 12 and the receiver 14 and trusted 
by them both. The sender 12 has a private key (S-SK) and a public key (S-PK), 
the receiver 14 has a private key (R-SK) and a public key (R-PK) and the CA has 
a private key (CA-SI^ and a public key (CA-PK). The CA-PK is provided to both 
30 the sender 12 and the receiver 14 in order for authenticated communication to 
occur. Clearly, the CA-PK must be provided in an authenticated way so that the 
sender 1 2 and the receiver 14 can be certain of its source. 
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The sender 12 generates a certificate-signing request (CSR), wtiicli is sent to tiie 

CA 16. The sender 12 proves its identity to the CA 16 (either by a user of the 

sender 12 sending some personai data or , by a private code being used which is 
5 present in the sender 12). The sender 12 also sends its public key S-PK within the 

CSR. The CA 16 signs the personal data or the private code and the public key S- 
' PK together vi^ith a unique digital signature in' order to prove that they con-espond. 
' The signed certificate is returned to the sender 12. The receiver 14 carries out a 

similar procedure with the CA 16 in order to obtain its own signed certificate. 
10 When the sender 12 wants to talk to the receiver 14, a handshake between them 

is required in which the sender 12 and the receiver 14 exchange their digital 

certificates (this exchange is not encrypted). 

The sender 12 and the receiver 14 can then verify the received signed certificates 
15 by using the CA-PK to ensure that they were authenticated by the CA 1 6 and so 
can be trusted. Since the sender 12 and the receiver 14 now each have the public 
key of the other, confidential and authenticated communication can take place. In 
reality the sender 12 and the receiver 14 may send an authenticated certificate 
(discussed below) rather than only sending authenticated public keys. 

20 

Generally CAs are an^ngied in a hierarchy originating from a common root. This 
hierarchy is called the public key infrastructure. This means that CAs can be 
authenticated to each other. 

25 Compiared with symmetric-key encryption, public-key encryption requires rnore 
computation and is therefore not always appropriate for large amounts of data. 
Therefore, RSA or some other form of public-key encryption Is only used at the 
protocol handshake part of a communication in order to generate a master secret. 
This is shown in Figure 2 in which public key encryption is used to negotiate a 

30 session key. Since data communication is bi-^directional, in the following reference 
will be made to a ciieht and a server ratiier than a sender and a receiver. 
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Initially, both a client 22 and a server 24 have a public key from a certification 
authority (CA-PK). The client 22 and the sen/er 24 each go Into the certification 
authority to obtain an authenticated certificate, which is signed by the certification 
authority's GA-SK. In addition to a public key (for exanriple of the client 22 or the 
server 24), a certificate Includes the name of the entity it identifies (in the form of a 
distinguished name), an expiration date (validity period), the name of the 
certification authority (in the fonn of a distinguished name, referred to as DN in the 
following) that issued the certificate, a serial number and other information. l\^ost 
Importantly, a certificate always includes the digital signature of the issuing 
certification authority. The certification authority's digital signature aJlows the 
certificate to function as a "letter of introduction" for users who know and tmst the 
certification authority but do not know the entity identified by the certificate. 

A DN is a unique identifier for an individual, for example to identify a person or a 
terminal node. If the DN is included In a digital certificate and the certificate is 
signed by a trusted CA, it is believed that the identified indrviduai is real and that 
the individual having the private key con-esponding to the public key in the 
certificate is this real individual. In effect, the certificate issued by the certification 
authority binds a particular public key in the name of the entity or entities which 
the certificate identifies. Before a CA signs a certificate it verifies that the indivkluai 
Is the one that is claimed. This verification may include tiie analysis of the 
personal identification information, a signature or some other infonnation. In this 
embodiment, the distinguished name (DN) identifies tiie client 22 or the sender 24. 

Altiiough the digital certificate includes aii of the elements described in tiie 
foregoing, only the public key and the party's DN will be discussed in the following. 

Once the authenticated certificates have been exchanged, their signatures can be 
verified and thus authenticated by the client 22 and the sen/er 24 using the CA-PK 
in order that each party is enable to obtain tiie public key of the other. Each party 
generates a random number (RND, and RNDj) and encrypts it with tiie other 
party's public key. Ihe encrypted random numbers are then transmitted to the 
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opposite party and dan be decrypted using the private l<eys. Since both parties 
now possess both randdm numbers these can be combined to generate a master 
secret (also refered to as a session Icey). Once this has been generated the client 
22 and the sender 24 can communicate using a relatively fast symmetric-l<ey 
5 encryption method such as DES, 3DES or RC5. Figure 2 is shown and described 
simply to illustrate the principles ' involved. Particular implementations of the 
an-angement of Rgure 2, for example using SSL or WTLS, may be more 

♦ 

complicated in practice. 

10 Problems can occur when an encryption method from TCP/IP and from another 
communication protocol having its own security layer are used together. This 
situation can occur, for example, when mobile terminals operating according to the 
Wireless Application Protocol (WAP) are used to access the Internet. In order to 
provide secure connibctlon the Internet Uses security protocol layers like Transport 

15 Layer Security (TLS) (specified by RFC 2246) arid Secure Soclcets Layer (SSL) (a 
de facto standard developed by Netscape Corporation). The equivalent security 
protocol layer used in WAP networks is Wireless Transport Layer Security (WTLS) 
(standardised by the WAP Forum). 

20 Although Internet and WAP networics are very similar, they are not compatible and 
so It is necessary to carry out content translation between Hypertext Markup 
Language (HTML) and Wireless Mari<up Language (WML) and between HTTP 
and WSP layers. The problem is illustrated with reference to Figure 3. A WAP 
stack 32 (embodied in a client) is connected to a TCP/IP stack 34 (embodied in a 

25 server) via a gateway 36. The WAP stack 32 has protocol layers Wireless 
Datagram Protocol (WDP), Wireless Transport Layer Security (WTLS), Wireless 
Transaction Protocol ^WTP) and Wireless Session Protocol (WSP). It provides 
WML content. The TCP/IP stack 34 has protocol layers Internet Protocol (IP), 
Transaction Control Protocol (TCP), Secure Sockets Layer (SSL) and l^lypertext 

30 Transport Protocol (HTTP). It provides HTML content . , 

In the case of WAP and TCP/IP stacks, if the WTLS and SSL layers are active, 
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and the gateway 36 does not possess the necessary keys to decrypt messages 
which are being transmitted, layers located abiove the encryption layers cannot be 
modified in the gateway and thus conversion between them (between WSP and 
HTTP or between WML and HTML) is not possible. Since the gateway cannot 
5 access the required secret keys (usually they are stored in a physically tamper^ 
resistant device in a way that they cannot be read out from them), another 

I 

encryption scheme should be used. The client should authenticate the gateway 
and the gateway should authenticate the origin server and the server should 
authenticate the gateway and the gateway should authenticate the client In this 
10 scheme It is necessary that both parties trust the gateway. Since cun'ent security 
protocols (SSL, TLS, WTLS) are assuming end-to-end encrypted connections they 
cannot support this kind of encryption scheme. 

According to a first aspect of the inyentton there is provided a method for 
15 authenticating a first party and a second party to each other via a gateway, the 
method comprising the steps of: 

providing the gateway with a gateway public key and a corresponding gateway 
private key; 

providing the first party and the gateway with a common public key to authenticate 
20 the source of information transferred from one to the othen and 

providing the second party with the gateway public key to authenticate information 
received from the gateway, the gateway public key be.ing different to the common 
public key. . r 

25 Pref erably.the first party is a client. Preferably the second client is a sender. 

Preferably the second party is told that the gateway public key is a public key from 
a certification authority. Therefore, when the second party receives a certificate 
from the gateway which has been signed by the gateway private key, the second 
30 party uses the gateway public, key to verify that this signed certificate has come 
from the same source as the gateway public key and consequently accepts as if 
the certificate has come from the certification autiiorlty. In this way, the gateway is 
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able to include Information In the certificate that It sends to the second party to 
convince the second party that the gateway Is, In fact, the first party. 



Preferably the common public key is the public key of a real and trusted 
5 certification authority. 

According to a second aspect of the invention there is provided a method of 
' authenticating a first party to a second party via a gateway the first party using an 
encryption protocol between itself and the gateway and the second party using an 
10 encryption protocol between itself and the gateway the method comprising the 
steps of: 

installing In the second party that the gateway is a trusted certification authority; 
the gateway issuing a digital certificate authenticating the first party; and 
the second party verifying the digital certificate in order to confimi to the second 
15 party that the digital certificate comes from the trusted certification authority. 

Preferably the encryption protocols between the first party and the gateway and 
between the second party and the gateway are different. Preferably the encryption 
protocol between the first party and the gateway is WTLS. Preferably the 
20 encryption protocol between the gateway and the second party is SSL 

According to a third aspect of the invention there is provided a method for 
authenticating a client and a server to each other via a gateway, the method 
comprising the steps of: 
25 providing the client with a client public key and a con;esponding client private key; 
providing the client with a client certificate; 

providing the server with a server public key and a con'esponding server private 
key; 

providing the sender with a server certificate; 
30 providing the gateway with a gateway public key and a con'esponding gateway 
private key; and 

providing the gateway with a gateway certificate. 
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Preferably the client certificate is issued by a common CA. Preferably tiie client 
certificate contains the ciienfs distinguished name and the client public ksy. The 
client certificate may be signed, and thus, authenticated, by a trusted certificate 
authority. - 

Preferably the server certificate contains the server's distinguished name and the 
server public key. it may also contain other items of information. This server 
certificate is signed and thus authenticated by a trusted certificate authority. 
Preferably this certificate authority is the same as that which signed the client 
certificate. Alternatively It may be a different certification authority. 

Preferably the gateway certificate contains the server's distinguished n<ame and 
the gateway public key. This gateway certificate may. be signed and thus 
authenticated by a trusted certificate authority. Preferably this certificate authority 
Is the same as that which signed the sender certifiOate. Alternatively it may be a 
different certification authority. The trusted certificate authority may sign the 
gateway certificate (containing the sen/el's distinguished name) only if the server 
and the gateway belong to the same organisation, since only one organisation 
may possess the same distinguished name for different public Iceys. 

Preferably the gateway simulates a certification authority. Preferably tiie gateway 
public key provided to the server is indicated to the server as being the public key 
of a certification authority. Preferably the gateway generates different public- 
private key-pairs for every client, each key-pair comprising a generated client 
public key and a generated client private key. The gateway may generate different 
certificates in tiie name of different cliente The gateway may sign these certificates 
witii the gateway private key. Preferably these' certificates contain the 
distinguished name of the client and the generated client public key. As an 
extension these generated client certificates may include the original client 
certificate in order for the server to get the autiientic client public key. 
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Preferably the method comprises the step of providing the server with an identifier 
Indicating Its origin. Preferably it comprises the' step of providing the gateway with 
an identifier indicating a common origin with the server. Preferably ft comprises 
the step of requesting certificates for the server and the gateway corresponding to 
5 the common identifier of the server and the gateway, but containing different 
public Iceys belonging to the server and to the gateway respectively. 

I 

Preferably the method comprises a handshake in order to authenticate each party 
to the other and to- negotiate one or more session keys. This may be a double 

10 handshake. In one embodiment, the client and the gateway execute a common 
first handshake authenticating each other (using the client certificate and the 
gateway certificate) and negotiating a master secret (from which a session key 
can be calculated). Once the client Is authenticated to the gateway the gateway 
may use the generated client private key and the generated client certificate 

15 belonging to the authenticated client to execute a second handshake with the 
server (at the server side the sender uses its server certificate). These two 
handshakes may overlap each other. As a resuK of the second handshake the 
gateway and the server may negotiate a comrtion master secret (from which the 
session key can be calculated). 

20 

In this way, the invention provides that the client accepts the authentication from 
the gateway, because in the gateway certificate the server's distinguished riame is 
included and the certificate is signed by a trusted certificate authority. 
Furthermore, the server aijcepts the authentication from the gateway, because in 
25 the generated client certificate the client's distinguished name Is included and the 
certificate is signed by the gateway, which the server accepts as a toisted 
certificate authority. 

The handshake may be a handshake which occurs prior to communication 
30 according to WTLS. It may be a handshake prior to SSL or TLS. Preferably it 
comprises a handshake procedure prior to communication by both WTLS and SSL 
or TLS. 
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The invention may also be considered to be a metliod of translating encrypted 
content according to a first protocol into content according to a second protocol or 
to be a metiiod for enedbling sucli translation to occur. Such a method requires 
5 each party to be authenticated to the other via an intemiediate gateway and so 
can use the methods of authentication according to the pre\^ous aspecte of the 
invention. 

According to a fourtii aspect of the invention there is pro>^ded a transaction 
10 system comprising a first party and a second party which communicate via a 
gateway communication between the parties requiring authentication of the first 
party to the second party using an encryption protocol between the first party and 
the gateway and an encryptiori protocol between the second party and ttie 
gateway wherein: 

15 the gateway comprises digital certificate signing rrieans to issue a digital certificate 
autiienticating the first party; 

tiie second party comprises digital certificate verification means corresponding to 
the digital certificate signing means of the gateway which verifies the digital 
certificate in order to confirm to the second party tiiat the gateway signed digital 
20 certificates are authentic. 

Preferably the transaction system is a communications system. 

According to a fifth aspect of the invention there is provided a gateway through 
25 which a first party and a second party can communicate, communication between 
tiie parties requiring authentication of the first party to the second party using an 
encryption protocol between the first party and the gateway and an encryption 
protocol between the second party and the gateway, the gateway comprising 
digital certi'ficate signing means to issue a digital certificate authenticating the first 
30 party the signing means of the gateway corresponding to verification means of the 
second party which verifies ttie digital certificate in order to confirm to the second 
party that the gateway signed digital certificates are autiienti'c. 
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According to a sixth aspect of tlie invention there is provided a computer program 
product for authenticating a first party to a second party via a gateway the first 
par^ using an encr^n^tion protocoi betweer;i itself and the gateway and the second 
party using an encryption protocol between itseif and the gateway the computer 
program product comprising: 

computer executable code means to indicate' to the second party that the gateway 
is a tnjsted certification authority; 

computer executable code means to enable the gateway to issue a digital 
certificate authenticating the first party; and 

computer executable code means to enable the second party to verify the digital 
certrticate in order to confirm to tiie second party tiiat the digital certificate was 
issued by a ti'usted certification authority. 

According to a seventii aspect of the invention there is provided a method of 
content delivery from a content provider to a temilnal through a communications 
networl< in which tiie content provider and the terminal authenticate each other via 
a gateway, tiie method comprising the steps of: 

providing the gateway with a gateway public icey and a corresponding gateway 
private icey; 

providing the terminal and the gateway witii a common public Icey to authenticate 
the source of Infomiation transferred from one to the other; and 
providing the content provider with the gateway public Icey to authenticate 
information received from the gateway, the gateway public key being different to 
the common public Icey. 

According to an eighth aspect of the invention there is provided a method of 
content delivery from a content provider to a terminal through a communications 
networlc in which the content provider and the terminal authenticate each otjier via 
a gateway tiie terminal using an encryption protocol between itself, and the 
gateway and the content provider using an encryption protocol between itseif and 
the gateway tiie method comprising the steps of : 
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the content provider determining tliat the gateway is a trusted certification 
autfiorify; 

the gateway issuing a digital certificate authenticating the terminal; and 

the content provider verifying the digital certificate in order to confinn to the 

content provider that the digital certificate comes from the trusted certification 

authority. 

According to a ninth aspect of the invention there is provided a metiiod of content 
delivery from a content provider to a terminal through a communications network 
in which the content provider and the terminal auti;ij5nticate each other via a 
gateway the method comprising the steps of: 

providing the client with a client public key and a corresponding client private key; 
providing the client with a client certificate; 

providing the server with a server public key and a corresponding sen^r private 
key; 

providing the server with a server certificate; 

providing the gateway with a gateway public key and a corresponding gateway 
private key; and 

providing the gateway with a gateway certificate. 

The invention is suitable for telecommunications, and is particulariy suitable for 
mobile terminals, such as mobile telephones, personal digital assistants, e-books 
or browsers. It Is applicable to sepurely accessing the Internet by using mobile 
terminals. In one embodiment it can be used for providing end-to-end security 
between a mobile terminal using Wireless Application Protocol (WAP) and a 
WWW server using internet security protocols. 

An embodiment of the invention will now be described with reference to the 
accompanying drawings In which: 

Figure 1 shows communication between a sender and a receiver; 
Figure 2 shows steps in generating a master secret; 
Figure 3 shows communication via a gateway; 
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Figure 4 shows communication via a gateway according to the invention; and 
Figure 5 shows a flowchart of steps. 

Figure 4 shows a communications system 40 comprising a client 42 (such as a 
5 mobile telephone) having a WAP sXaok, an origin server 44 having a TCP/IP stack, 

I 

a gateway 46 and a certification authority (CA) 48. The gateway 46 is owned by 
the operator of the origin server 44, that Is the origin server 44 and the gateway 46 
are under common control. The CA 48 Is accessible by the client 42, the origin 
server 44 and the gateway 46 for authentication of a certificate belonging to each 
10 of these parties. The origin server 44 is located In a communications network. In 
this embodiment of the invention, it is located in a wireless telecommunications 
network. 

The CA 48 is an independent authority, it issues a digital certificate certifying that 
15 a party has proved its Identity to the CA. Since each party tnists the CA, they 
accept digital certiffcates which have been digitally signed by the CA which show 
tliat the other parties have been personally identified by the CA. The CA 48 has a 
private and public key pair CA-SK and CA-PK. 

20 The client 42 has a key pair comprising a public key (C-PK) and a private key (C- 
SK). It has a certificate comprising the following Information: 
(I) the C-PK; 

(li) a validity period for the certificate; 
(iiO the client's DN; 
25 (rv) the Issuer's DN (the CA's DISO; and 

(v) digital signature of the above Information sigried by tiie Issuer's private key (the 
CA-SK). 

The client 42 also has the CA-PK from the CA 48. This may be pre-lnstalled, for 
30 example on manufacture of the client or manufacture of a part of the client (for 
example manufacture or configuration of a SIM card), or it may be Installed at a 
later date. 
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The origin server 44 has a key pair comprising a publib Icey (S-PK) and a private 
key (S-SK). It has a certificate comprising the following infonnation: 
(i)theS-PK; 

00 a vaiidity period for the certificate; . 
(lii) the origin server's DN, 

(iv) the issuer's DN (the CA's DN); and 

(v) digital signature of the above inforaiation signed by the issuer's private key 
(CA-SK). 

Instead of having the CA-PK from the CA 48, the origin sen/er 44 has a public key 
from the gateway 46 as will be explained below. 



The gateway 46 has a key pair comprising a public key (G-PK) and a private key 
15 (G-SK). It has a certificate comprising, the following information: 

(i) theG-PK; 

(ii) a validity period for the certificate; 

(ill) the gateway's DN (which is the same or at least belongs to the same 
organization as the sen/er); 
20 (iv) the issuer's DN (the CA's DN); and 

(v) digital signature of the above Infonnatlon signed by the issuer's private key 
(CA-SK). 

The gateway 46 aiso has the CA-PK from the CA 48. The CA-PK is presented to 
25 the gateway 46 in a trustworthy way. For example, the CA-PK may be loaded into 
the gateway 46 by floppy disk. 

The above relates to an embodiment in which all certificates are issued by the 
same CA. However, there may be several CAs. For example, there may be a CA- 
30 C which signs the client's certificate with a private key CA-C-SK, a CA-G which 
signs the gateway's certificate with a private key CA^G-SK and a CA-S which 
signs the sender's certificate with a private key CA-S-SK. .The public keys CA-C- 
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PK and CA-S-PK are given to the gateway and the public key CA-G-PK Is given to 
the client. The gateway public key G-PK is given to the server. 

As is mentioned above, the G-PK is loaded into the origin sender 44 rather than 
the GA-PK. The origin server 44 is informed that G-PK is actually the CA-PK. 
Since the origin server 44 and the gateway 46 are under control of the same 
organisation and may be located in the same (physically protected) location (and 
perhapis even in the same machine), loading the CA-PK into the gateway 46 and 
the G-PK into the origin server 44 as the CA-PK is straightfonvard. The public 
keys may be loaded directly or may be provided over a connection. All that is 
important is that the G-PK should be downloaded in an authentic way. 

It may be the case that the origin server 44 and the gateway 46 are not under the 
control of the same organisation. This would result in a lower lever of security 
although this might be acceptable in certain circumstances. 

It should be understood that, in the certificates of the origin server 44 and the 
gateway 46, extensions such as the validi^ period and the issuer's ON are 
identical. In addition, the origin server's DN and the gateway's DN are identical. 
However, in one embodiment of the invention, the gateway's DN and the origin 
server's DN differ slightly but ate identical enough to indicate that the DNs 
represent the same organisation. For example, the origin server's DN may 
represent a bank server and the gateway's DN may represent another server 
within the same bank. 

Operation of the system will now be described witii reference to the flowchart of 
steps of Figure 5. A protocol handshake is executed between the client 42 and the 
gateway 46 as follows. The clienfs certificate (signed by the CA-SK of the CA 48) 
Is sent to the gateway 46. The gateway 46 is able to verify this signed certificate 
by using the CA-PK and thus it obtains the C-PK, the origin of which is 
authenticated by the CA 48. In response, the gateway 46 sends ite certificate 
(signed by the CA-SK) to the client 42. The client 42 is able to verify this signed 
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certificate by using the CA-PK and thus it obtains the.G-PK, the origin of which is 
authenticated by the CA 48. Since the gateway certificate has the origin sender's 
DN, the client believes that the gateway 46 is the origin server 44. Since the client 
42 and the gateway 46 each have the public key of the other, they can 
communicate in a way which is authentic and confidential and agree on a master 
secret according to the security protocol which is to be used (for example WTLS). 
The client 42 and the gateway 46 can now communicate by using WTLS 
encryption. 

A protocol handshaice is now executed between the origin server 44 and the 
gateway 46 as follows. The gateway 46 generates a public key G-C-PK and a 
private key G-C-SK pair for each client, it is preferred to use a client-specific key- 
pair in order to provide different keys for different clients (for the purposes of non< 
repudiation). 

The gateway 46 generates a new certificate including the generated client public 
key (G-C-PK) and the client's DN. The new certificate is sigried by the G-SK of the 
gateway 46 and is sent to the origin server 44. In.^this way, the gateway 46 
generates a certificate that the origin server will accept as if it came from the 
client. The origin server 44 is able to verify this signed certificate by using the G- 
PK and thus it obtains the generated client public key (G-C-PK) and tiie client's 
DN. (Note: since the gateway 46 does not participate in the certification hierarchy, 
this certificate will only be accepted by the origin server 44 and will be invalid to 
any other party, so the gateway 46 cannot impersonate the client in other 
situations.) 

Therefore, the origin server 44 believes that it is communicating with the client 42 
because the generated client certificate has the client's DN and the internal 
variables of the SSL iayer indicate that there is a secure connection to the client. 
In this way programs at the application level in the origin server 44 will not notice 
any differences and will accept the authentication. The gateway believes that 
client's DN relates to a party that it should trust because the original client 
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certificate is signed by a trusted CA Tlie origin server 44 has had its certificate 



gateway 48 is able to verify this signed certificate by using the CA-PK and thus It 
obtains the S-PK, the origin of which is authenticated by the CA 48. 

Since the origin server 44 has the generated client public key of the gateway (In 
this case G-C-PK) and the gateway 46 has the public key of the origin server (S- 
PK), the origin sen/er 44 and the gateway 46 can communicate in a secure way 
and agree on a master secret in a way similar to that described above in relation 
to Figure 2. The origin server 44 and the gateway 46 can now communicate using 
SSL (or TLS) encryption. 

Therefore, following the procedure discussed above, the client 42 and the origin 
server 44 can now both communicate securely with the gateway 46. Messages 
sent by either can be decrypted by the gateway 46, translated between WML and 
HTML in the gateway 46. and then re-encrypted In the name of the sender before 
being sent to the intended recipient. The gateway 46 Is treated by both the client 
42 and the origin server 44 as a trusted Interpreter In that both parties will talk 
directly to it over an SSL or WTLS secure connection. 

It should be noted In the foregoing that the gateway 46 operates in relation to the 
origin server 44 as a certification authority. However, it should be noted that in this 
role, the gateway 46 does not participate in the certification hierarchy and does 
not operate as an official certification authority to other parties except the server 
44. On the other hand the gateway 46 operates in relation to the client 42 as a 
server and has a signed certificate from a real certification authority, that Is the CA 
48. The origin sen^eV 44 and the gateway 46 are under common control and so 
the origin sender 44 can trust the gateway 46 and the client can accept that they 
belong to the same organisation. 



signed by the CA-SK and sends this signed certificate to the gateway 46. The 



In a preferred embodiment, the gateway 46 ains on the same machine as the 
origin server 44, that Is, it has the sariie IP address, distinguished name and 
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certification. In this case, tiie client 42 will not notice anytiiing unusual about the 
translation. • 

If speed of establishing secure communication between the client 42 and the 
5 origin sender 44 is important, scalable hardware-based algorithms can be used in 
the gateway. Aitemativeiy or additionally, generated client keys couid be 
calculated before the actual handshaice. 

In the same way that a client-specific Icey-pair can be used between the gateway 
10 and the server, a server-specific gateway can be used between the dient and the 
gateway. This could be the case if there are a number of different keys for 
different sen/ers. 

I 

Since the gateway decrypts and encrypts all messages, for certain operations, 
15 such as making payments, it may be prefen'ed to use another application level 
solution. In this case, the gateway 46 may insert the clienfs original certifteation 
into the generated client-certification as an attachment, so that real end-to-end 
authentication above the application level may be perfonned. The original 
certificate may then be used for evaluating digital signatures. 

20 

One can easily see that this solution is independent from the differences between 
WTLS and SSL and works also in cases where the client or the server or both are 
not authenticated. In other words, in SSL AND WTLS, client or server side 
authentication is optional. If we disable one of these authentications tlie approach 
25 provided by the invention will also be able to handle that case. 

An advantage of the invention is that it does not require changes to be made 
either in WAP communication between the client 42 and the gateway 46 or in 
TCP/IP communication between the origin server 44 and tlie gateway 46. In this 
30 way it is compatible with appropriate standards. 
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The Invention provides end-to-end security between Internet servers and WAP 
clients In a way which enables seamless conversion between the SSL and the 
WTLS layers of the respective protocol stacte. 

6 Particular implementations and embodiments of the invention have been 
described. It is clear to a person skilled in the art that the invention is not restricted 
to details of the embodiments presented above, but that it can be Implemented in 
other embodiments using equivalent means without deviating from the 
characteristics of the invention. The scope of the invention Is only restricted by the 
10 attached patent claims. 
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Claims 

1. A method of authenticating a first party (42) to a second party (44) via a 
gateway (46) the first party using an encryptlcwi protocol between iteeif and the 
gateway and the second party using an encryption protocol between itself and the 

5 gateway the method comprising the steps of: 

installing in the second party that the gateway is a trusted certification authority 
(48); 

the gateway issuing a digital certificate authenticating the first party; and 
Ihe second party verifying the digital certificate in order to confinn to the second 
10 party that tiie digitai certificate comes from tiie tnisted certification authority. 

2. A method according to claim 1 in which the encryption protocols between the 
first party (42) and the gateway (46) and between the second party (44) and the 
gateway are different. 

15 • 

3. A method according to claim 2 in which the encryption protocol between the first 
party (42) and the gateway (46) is WTLS and the ericiyption protocol between the 
gateway and the second party (44) is SSL 

20 4. A method according to any preceding claim in which a gateway public Icey is 
provided to the second party (44) and Is indicated to the second party (44) as 
being the public key of the trusted certification authority (48). 

5. A method according to any preceding claim in which the gateway (46) 
25 generates different public-private key-pairs for a plurality of first parties, each key- 
pair comprising a generated first party (42) public key and a generated first party 
private key. 

6. A method according to claim 5 in which tiie gateway (46) generates different 
30 certificates in the name of different first parties. 



7. A method according to claim 6 in which the gateway (46) signs tiiese different 
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certificates with a gateway private key. 

8. A method according to claim>6 or claim 7 in which these different certificates 
contain a distinguished name of the first party (42) and a first party public Icey. 

9. A method according to any preceding claim which comprises the step of 
providing the second party (44) with an identifier indicating its origin. 

10. A method according to claim 9 which comprises the step of providing the 
gateway (46) with an Identifier indicating a common origin with the second party 
(44). 

11. A method according to claim 10 which comprises the step of requesting 
certificates for the second party (44) and the gateway (46) corresponding to the 
common identifier of the second party and the gateway, but containing different 
public keys belonging to tiie second party and to the gateway. 

12. A method according to any preceding claim which comprises a handshake in 
order to authenticate each paxi^ to the other and to negotiate one or more session 
keys. 

13. A method according to claim 12 in whteh the handshakei is a double 
handshake. 

14. A method according to any preceding claim in which the first party (42) and the 
gateway (46) execute a comrnon first handshake autiienticating eac^ other and 
negotiate a master secret. 



15, A method according to claim 14 in which the gateway (46) uses a first party 
(42) private key and the first party certificate to execute a second handshake with 
the second party (44). 
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16. A method according to claim 14 or claim 15 in which at least one of the 
handshakes is a handshake which occurs prior to communication according to 
WTLS. 

5 17. A method according to claim 14 or claim 15 in which at least one of the 
handshakes is a handshake which ocQurs prior to SSL or TLS. 

18. A method according to any preceding claim in which the first party (42) is a 

« 

client and the second party (44) is a server. 

10 , 

19. A method according to any preceding claim which comprises the step of 
providing the first party (42) and the gateway (46) with a common public key to 
authenticate tlie source of information transferred from one to the other the 
common public key being the public key of the trusted certification authority (48). 

15 . 

20. A transaction system (40) comprising a first party (42) and a second party (44) 
which communicate via a gateway (46) communication between the parties 
requiring authentication of the first party to the second party using an encryption 
protocol between the first party and the gateway and an encryption protocol 

20 between the second party and the gateway wherein: 

the gateway comprises a digital certificate signer (48) to issue a digital certificate 
authenticating the first party; 

the second party comprises a digital certificate verifier con-esponding to flie digital 
certificate signer of tiie gateway which verifies the digital certificate in order to 
25 confirm to the second party that the gateway signed digital certificates are 
authentic. 

21. A transaction system (40) according to claim 20 comprising a communications 
system. 

30 

22. A transaction system (40) according to claim 21 comprising a wireless 
telecommunications system having a network and a plurality of mobile temninals. 
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23. A gateway (46) through which a first party (42) and a second party (44) can 
communicate, communication between the parties requiring authentication of the 
first party to the second party using an encryption protocol between the first party 
and the gateway and an encryption protocol between the second party and the 
gateway, the gateway comprising a digital certificate signer (48) to issue a digital 
certificate authenticating the first party the signer of the gateway corresponding to 
a verifier of the second party which verifies the digital certificate In order to confirm 
to the second party that the gateway signed digital certificates are authentic. 

24. A gateway (46) according to claim 23 which comprises a server (44). 

25. A computer program product for authenticating a first party (42) to a second 
party (44) via a gateway (46) the first party using an encryption protocol between 
itself and the gateway and the second party using an encryption protocol between 
itself and the gateway, the computer program product comprising: 

computer executable code to indicate to the second party that the gateway is a 
trusted certification authority (48); 

computer executable code to enable the gateway to issue a digital certificate 
authenticating the first party; and 

computer executable code to enable the second party to verify the digital 
certificate in order to confimn to tiie second party that the digital certificate has 
been issued by the trusted certification authority. 

26. The computer program product according to claim 25 which is stored on a 
computer readable medium. 

27. A metiiod of content delivery from a content provider (44) to a terminal (42) 
through a communications networic in which the content provider and the terminal 
authenticate each other via a gateway (46) the terminal using an encryption 
protocol between Itself and the gateway and tiie content provider using an 
encryption protocol between itself and the gateway the method comprising the 
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steps of: 

the content provider determining that the gateway is a trusted certification 
authority (48); 

the gateway issuing a digital certificate authenticating the terminal; and 
5 the content provider verifying the digital certificate in order to conflmi to the 
content provider that the digital certificate comes from the tmsted certification 
authority. 

28. A method for authenticating a first party (42) and a second party (44) to each 
10 other via a gateway (46), the method comprising the steps of: 

providing the gateway with a gateway public key and a con-esponding gateway 
private key; 

providing the first party and the gateway with a common public key to authenticate 
the source of information transferred from one to the other; and 
15 providing the second party with the gateway public key to authenticate Infomiation 
received from the gateway, the gateway public key being different to the common 
public key. 
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